A model consists of multiple diagrams. Each diagram represents a particular piece of the model and the various conditions or states that this piece of the model can be in. These pieces correlate to aspects of traditional PRA modeling and range from small-scale components to a large scope, overall plant response and design. A diagram contains multiple states with the events that can occur, actions that can be executed and variables used. These all define how the simulation may sift through the diagram over time.
Additionally, some diagrams (Component and State) can also be evaluated to a Boolean depending on which stat they are currently in. This is a key feature that when combined with a Component Logic Event, can greatly simplify a model. Unlike the more general diagrams like plant response, these diagrams are restricted to only be in one state at a time, in order to execute the evaluation process.
Types of diagrams include Component, System, Plant Response, and External Simulation Integration.
Once components are modeled, a Fault Tree from traditional modeling can be directly converted into System diagram with two states and a special event used to evaluate Boolean logic. The two states are "Active" and "Failed", with a "Component Logic" event in the active state evaluating the assigned logic whenever a component diagram state changes. If the logic ever evaluates to false, then the current state shifts from "Active" to "Failed". (See Figure 10) This is similar to a typical PRA model except the logic does not contain any probabilities, just references to the Component diagrams.
Finally, we have Plant Response diagrams. These diagrams are the main scenarios to be evaluated, similar to Event Trees. This diagram has a starting state such as Normal Operation and a Mission Time state. Other states can do general evaluation and movement or be a key end state. Here the user defines the various states and events that drive the simulation from an initiating event to a desired end state.
For example, if an evaluation is needed for "loss of offsite power" (LOSP) that failure rate is added to the normal running start state for the Plant Response diagram. If that event occurs, the state shifts to the LOSP state. The LOSP state immediately starts new states to evaluate the related systems and waits for any events that trigger new key state. When the evaluation ends, all key end states that are in the current state list are logged with the timing and paths of all the states and events that lead to this state.
EMRALD can be loosely coupled with external solvers through a network messaging protocol. Currently, EMRALD can provide direction to the Neutrino 3D fluid solver analysis module. A planned enhancement is to make this functionality available to other applications through an open-standard built upon the XMPP messaging protocol.
Integrating 3D simulation into the state diagram model is just a matter of starting the user specified 3D simulation when needed and receiving events that can trigger a state change. For each component that can have a failure from the 3D simulation, we must add a 3D simulation failure event in the component state diagram.
Then, in the Plant Response diagram we need a "3D Sim Action" to start the simulation. As an example, we will add a Tsunami initiating event probability to the diagram show in Figure 11. This event triggers a move to the Tsunami state, which possibly triggers LOSP, starts the 3D simulation, and starts evaluation of the systems. Evaluating the state diagrams now consists of evaluating the next state diagram event or waiting for the next 3D simulation event.
